In event management, the term “event” means an event to be monitored. The event to be monitored may for instance be a new entry or record in a data file assigned to a particular device, component or piece of equipment. The event may also be used to refer to a capacity utilization of a piece of equipment, or in other words, is directed to a question of how many processing requests are made for a limited resource at a certain time.
Which parameters or data the event to be monitored relates to may depend for one on a current task or instruction and for another on the component or piece of equipment to be monitored.
A type and orientation of the monitoring may also differ. For instance, the event management may be used for a configuration and sequencing and/or error behavior of the system and/or of individual components of the system.
Typically, the components to be monitored are part of a network, which typically includes various kinds or generic types of components. In a medical network, for instance, such types of equipment as CT (Computed Tomography), MRI (Magnetic Resonance Imaging), and X-ray systems, and the like are provided, which each have different events of interest. A plurality of templates may therefore exist for a plurality of types of components.
In event management, a change of state of the monitored component that is to be detected and observed is typically defined. Different events may also be provided for one and the same component at different times.
Typically, the monitoring is done with a substantially narrow time-interval pattern, so that the component is monitored nearly continuously.
Depending on the application, from a set of events, a partial set can be formed, the so-called events of interest. These events of interest are typically relevant to a particular application and may vary from one application to another.
For investigating the question of whether an event to be monitored or an error has occurred or not, specific devices are employed, such as sensors, which either belong to the monitored component or are assigned to it. In the latter case, an occurrence of an event in the monitored component can also be ascertained outside the component and is executed via a so-called external agent.
The external agent is preferably a software module that takes on monitoring tasks. However, in some applications, the external agent may be appropriately entrusted with other tasks as well. This agent is typically assigned to a terminal unit to be monitored or to the component to be monitored and receives the assigned tasks and executes them at forwarded times or within a defined time interval.
In some cases, ascertaining or detecting the event exactly at the instant when it also occurs in the component may be desired, or in other words performing real-time monitoring. In other cases, performing the monitoring chronologically separately from or offset from the occurrence of the event may be appropriate.
An outcome of the monitoring is an event report. Depending on the application, the information and parameters that the event report should include can be defined, such as the type of event, priority, time of occurrence of the event, status of the component before and/or after the occurrence of the event, and so forth. Typically, the event report is prepared at the monitored component and forwarded to a central authority, preferably an event management station. This station administers all the event reports received and can take on still other control tasks as well. Typically, the event management station includes a graphic user interface.
The events of interest are defined for a particular component to be monitored in so-called templates (also called document templates). The templates include tasks for monitoring the component or terminal unit. Typically these tasks search for specific text strings in data files (such as an error report in a specific log file) and/or polling of hardware-specific parameters of the terminal unit (for instance on the order of “switch in open or closed position (ON/OFF position)” or “connection does/does not exist”). Once the template for the component has been generated, the component or the corresponding external agent is configured with the template so that the events of interest can be detected. If a setting changes in the terminal unit (for instance, if a new software version is installed or downloaded), then the template pertaining to this unit must be suitably adapted or modified. This adaptation or modification is done manually. This manual adaptation has the disadvantage that the risk of error increases, since the user may overlook the adaptation or modification or forget to do it or may perform it erroneously.
Moreover, in complex systems with various types of terminal units and manifold uses, the monitoring task is necessarily also more complex. As such, generating, maintaining and administering the templates to be monitored involve a great deal of work. Even slight changes in a terminal unit may still require major adaptation of the templates. The templates may need to be continuously maintained so that a monitoring system that operates without error can be assured. These required or desirable adaptations and continuous maintenance make increased demands of an event management tool. As such, the user may desirably be supported as extensively as possible in his work with the event management tool.
Moreover, there has been a disadvantage that upon a change of event management tool, all the old templates created thus far must be discarded, since they can no longer be used for the new tool. This discarding of old templates requires additional repeated development work.